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Routing Information Processing for Network Hiding Scheme 



FIELD OF THE INVENTION . 

The present invention relates to a method and device for processing a routing in- 
formation in a packet data network, such as an Internet Protocol (IP) Multimedia 
5 Subsystem (IMS) provided on top of a packet data network to offer voice and mul- 
timedia services e.g. for third generation mobile devices, or any other IP-based . 
network. 

. BACKGROUND OF THE INVENTION 

The Session Initiation Protocol (SIP) as defined in the Internet Engineering Task 
.10 Force (IETF) specification RFC 3261 , provides an emerging standard for setting 
up multimedia sessions on the Internet: Its basic capabilities are setup modifica- 
tion arid tear down of any communication session, .so it is a signaling protocol. SIP 
also provides personal mobility, meaning that a consumer is reachable via a single 
address regardless of its current point of attachment to the network. 



15 In order to support multimedia services, seamless mobility and efficient multiparty 
conferencing, the IP layer has been enhanced. Mobile IP allows terminals to move 
freely between different mobile networks. 

SIP is used to establish, modify and terminate sessions as well as send and re- 
ceive transactions. It provides personal mobility by allowing a user to dynamically 

20 register to the network with his communication address, i.e. SIP URI (Uniform Re- 
source Indicator). A session is usually a number of Real-time Transport Protocol 
(RTP) streams to be exchanged. Normally, a session is a combination of speech, 
audio and video streams, but it may also contain shared applications. A basic SIP 
network is composed of four types of elements i.e. User Agents (UA), Proxy Serv- 

25 ers, Redirect Servers and Registrar Servers. User Agents typically reside, in end- 
points such as IP phones, personal computers or mobile devices. They initiate re- 
quests and provide responses. Usually, UAs also have an interface to media han- 
dling and to the actual application software providing the user interface. Proxy 
servers are intermediaries, which receive and forward requests providing them 

30 with, e.g., routing or other services. Redirect servers simply respond to a request 
by asking its originator to redirect it to a new address. Registrar servers keep track 
on the actual points of contact of the consumers by accepting registrations from 
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the UAs. Registrar servers and the SIP registration procedure in general provide 
user mobility as the consumer is able to be reachable from any location via a sin- 
gle address. In this sense, they resemble Home Location Register (HLR) function- 
ality in the Global System for Mobile communications (GSM) networks. Each con- 
sumer is part of a domain and each domain runs at least one registrar, server, " 
which knows the location of its consumers if the are registered. 

SIP uses an address format common to Internet Mail, i.e ? "user@domain". The 
domain part is used to find the correct domain for the consumer and the user part 
is used to distinguish between individual consumers within a domain. SIP includes 
request and response messages comprising header fields, e.g: for defining where 
the request is to be sent next, the recipient address, the sender address etc. Fur- 
thermore, a SIP message may contain a payload portion for transmitting sub- 
scriber or. service specific information. 

Currently, the 3rd Generation Partnership Project (3GPP) is specifying IMS (IP 
Multimedia Subsystem) e.g. in its specification TS 23.228 as an access independ- 
ent subsystem which can be used in connection with different networks. IMS uses 
SIP for session initiation. Basically IMS is just an instance of a SIP network. It has 
a number of proxies and a registrar. The UA is situated in the terminal device or 
user equipment (UE). When two devices establish a session they talk to each 
other via Call State Control Function or Call Session Control Function (CSCF) 
elements. The UE is connected to a Proxy-CSCF (P-CSCF) arranged in a visited 
domain of the UE and providing basic IP connectivity and mobile management 
below it. The UE uses SIP to communicate with the P-CSCF which is similar to a 
SIP proxy server. In such a case, the consumer or subscriber of the UE is. roaming 
in the visited domain where the P-CSCF is located. The role of the P-CSCF is to 
provide emergency, call and other such services requiring specific knowledge of 
the visited domain. In case the consumer or subscriber is not roaming the UE is 
connected to a P-CSCF located in the home domain. Instead of radio access net- 
work also alternative access networks may be used. Instead of mobile or cellular 
terminal device also other kind of terminals may be used, especially in alternative 
access networks. 

Furthermore, an S-CSCF is always located in the subscriber's or consumer's 
home domain and takes the role of the SIP registrar and proxy servers, so that the 
UE can be registered at the S-CSCF using SIP via the P-CSCF. Furthermore, an I- 
CSCF is provided as another SIP proxy server responsible mainly for finding the 
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correct S-CSCF for a given subscriber or consumer. The S-CSCFs can be dy- 
namically allocated per registration in order to achieve efficient load balancing and 
error residency. An Application Server (AS) is provided as a SIP element dealing 
with the services provided to the UE. Separate ASs can be provided for different 
5 purposes. Finally, a Home Subscriber Server (HSS) is arranged for profile man- . 
agement and authentication. 

In IMS, subsequent SIP messages follow the path recorded into a Record-Route 
header of the initial request, while interrogating network nodes may drop them- 
selves out and other network elements stay on path. On the other hand, proxy 
10 servers in the middle may ask to remain on the signaling path for the duration of 
the call. This might be useful if the proxy offers some services to the call. 

Topology Hiding, also known as Network or Configuration Hiding, allows an opera- 
tor to hide the names and amount of the operator's SIP servers to another opera- 
tor. Furthermore it hides the topology of the network. Topology Hiding is specified 
15 within the IMS ( see e.g. 3GPP specification TS 23.228). Currently, a solution for it 
is described in the 3GPP specification TS 24.229, but this solution may lead to 
routing errors. Topology hiding can be applied by none, only one or both home . 
networks, it cannot be applied by a visited network. The present invention applies 
to any case where at least one of the home networks applies topology hiding. 

20 

Fig. 1 shows a schematic block diagram of an exemplary IMS network architecture 
in which the present invention can be implemented. The SIP Proxies in the IMS 
are called CSCF, and for the discussed problem underlying the present invention 
the following CSCF types of Fig. 1 are of relevancy. A P-CSCF-A 20 is a SIP out- 

25 bound proxy to which the mobile station UE-A 10 of User A is attached in its cur- 
rently visited domain 70. Furthermore, an I-CSCF-A1 30 is provided as the l-CSCF 
between the P-CSCF-A 20 and an S-CSCF-A 40, and acts as a topology hiding 
gateway (THIG). The S-CSCF-A 40 is the SIP Proxy providing services, provided 
for example by an AS 1 60 or other ASs (not shown), for User A in A's home net- 

30 work 72. Additionally, another I-CSCF-A2 34 is provided as the l-CSCF used by 
the S-CSCF-A 40 as the outgoing THIG when sending messages to the home 
network 82 of User B having a mobile station UE-B 12. The I-CSCF-A2 34 can 
also be the incoming THIG for messages from User B ! s home network 82. A fur- 
ther I-CSCF-B1 32 is arranged as the l-CSCF used by an S-CSCF-B 42 as the 

35 outgoing THIG when sending messages to the home network 72 of User A. The I- 
CSCF-B1 32 can also be the incoming THIG for messages from User A's home 
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network 72. The S-CSCF-B 42 is the SIP Proxy providing services for User B in 
B's home network 82. Another I-CSCF-B2 is the l-CSCF between the S-CSCF-B 
42 and a P-CSCF-B 22, and acts as a THIG. The P-CSCF-B 22 is the SIP out- . 
bound proxy to which the mobile station UE-B 12 of User 6 is attached in its vis- 
ited network 80. I-CSCF and THIG functionalities may be implemented separately. 
They also may be named and/or combined with other functionalities differently 
when used in SIP or other types of networks based e.g. on the specification of 
3GPP2 or IETF. . : 

All SIP signalling within the IMS goes at least through these four SIP Proxies in the 
above listed order, whenever topology hiding is applied in both home networks. 

It is to be noted here, that in the following "THIG" may be omitted in the notation "I- 
CSCF(THIG)" and "l-CSCF/THIG" for the sake of brevity. The' latter case notation 
denotes the same as the corresponding-former case. notation, e.g.. I-CSCF- 
B1(THIG) and I-CSCF-B1/THIG may be referred simply with i-cscf-bl. 

In the following, the conventional mechanism for network hiding is described and a 
sequencing problem of Route headers is shown. 

The current solution described in the 3GPP specification TS 24.229 works roughly 
in the following way: 

• all SIP messages (requests and responses) sent outside a users home 
network (either to the home network of the other user or the visited network 
of the served user) must traverse an l-CSCF/THIG in the users home net- 
work before leaving it; 

• the l-CSCF/THIG finds out all SIP URIs that were added by the home net- 
work to Via, Routei Record-Route, Path, Service-Route or any other 
header; 

• the l-CSCF/THIG applies an internal encryption mechanism and generates 
an encrypted name and/or address information which is called "token". 

For example, the following header can be sent outside of User As home network 
72 and is received (e.g. in an INVITE request) by I-CSCF-A2 34 (indentions and 
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line breaks as well as omission of branch parameter are just there for better read- 
ability): 

[I] Via: SIP/2.0/UDP s-cscf-a.home1.net, 
5 SIP/2.0/UDP i-cscf-a1.home1.net, 

SIP/2.0/UDP p-cscf-a. visited1.net, 
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] 

10 The I-CSCF-A2 34 now selects the entries belonging to its home network, which 

are: 

SIP/2.0/UDP s-cscf-a.home1 .net 
SIP/2.0/UDP i-cscf-a1.home1.net 

and hides them by generating a token (e.g. "1 987klwkmlkmva98u4q5") by what- 
ever local encryption mechanism. For better readability the token is further on rep- 
resented by the following string: 

20 Token( SIP/2.0/UDP s-cscf-a.home1.net, 

SiP/2.0/UDP i-cscf-a1.home1.net) 

The I-CSCF-A2 34 then forms a valid SIP Via header entry from the token and 
adds the tokenized-by tag: 
25 • 

SIP/2.0/UDP Token(SIP/2.0/UDP s-cscf-a.home1.net, 

SIP/2.0/UDP i-cscf-a1 .homei.net)@home1 .net.tokenized- 
by-home1.net 

30 inserts it to the Via header and adds its own address: 

[II] Via: SIP/2.0/UDP i-cscf-a2.home1.net, 

SIP/2.0/UDP Token(SIP/2.0/UDP s-cscf-a.home1.net, 

SiP/2.0/UDPi-cscf-a1 .homel .net)@home1 .net; 
35 - tokenized-by=home1 .net, 

SIP/2.0/UDP p-cscf-a.visited1.net, 
SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd] 
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The request traverses the other SIP-elements, until it reaches the end user, which 
sends back a response. The response to the request is routed based on the Via- 
header, so the response at one point hits I-CSCF-A2 34, showing exactly the 
same entry as shown in [II]. In order to be able to route inside the home network 
72, the I-CSCF-A2 34 selects all the entries which are indicated as "tokenized- 
by=home1.net" and decrypts them. Afterwards the Via-header looks again as in [I] 
and can be routed. Here there is no problem. 

In the case of the Record-Route header, the same mechanism is applied, but it 
creates a problem. 

User A sends a request to User B, the CSCFs put themselves into the Record- 
Route header, of which both users, when sending further requests that are related 
to this dialog (e.g. PRACK, UPDATE, BYE) form the Route header. User B sends 
back the Route header in the response to User A, so both have then the same 
route set. 

However, when creating the Route for a new request. User A obtains a reversed 
order of the Record-Route header after decryption. It is noted that the request was 
sent to an application server (AS) of the network operator in homel net and re- 
turned to the same S-CSCF, according to the conventional IMS service- 
procedures. 

As an example, the Record-Route header as received in an INVITE request by 
User B might look as fojlows: 

[III] RecordrRoute: p-cscf-b, 

i-cscf-b2, 

token(s-cscf-b, i-cscf-b1)@home2.net;tokehized- 

by=home2.net, 

}-cscf-a2, 

token(s-cscf-a, as1, s-cscf-a, i-cscf-a1)@home1.net; token- 

ized-by=home1 .net, 

p-cscf-a 

Hence, the sent order can be represented as: 1,2, (3,4), 5, (6,7,8,9), 10, where 
each number represents a specific one of the above servers or nodes passed dur 
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ing the routing procedure, and the numbers in brackets indicate tokenized or en- 
crypted routes. 

The Record-Route header is returned to User A in the response to the initial re- 
5 quest. User A now wants to send e.g. the PRACK or any subsequent request or 
any other request along the recorded route, therefore if creates the Route header 
by simply reversing the order of the Record-Route entries, in accordance with the 
. normal SIP procedure. Consequently, the Route header can be expressed as fol- 
lows: 

p-cscf-a, 

token(s-cscf-a, as1 , s-cscf-a, i-cscf-a1)@home1 .net; token- 
ized-by-home1.net 

i-cscf-a2, i / 
token (s-cscf-b, i-cscf-b1)@home2.net;tokenized- 
by=home2.net, 
i-cscf-b2, t 
p-cscf-b 

20 This routing order can be. represented as: 10, (6,7,8,9), 5, (3,4), 2, 1 . 

The request will thus be sent to any l-CSCF in the home network, not to the I- 
CSCF-A1 30, which should be first on the route. This problem results from the fact 
! that the entry of the I-CSCF-A1 30 has been maintained as encrypted by the I- 
CSCF-A2 34 when processing the initial request e.g. INVITE request. 

25 However, this wrong order of entries within the tokens cannot be reversed by the 
UE, neither UE-A 10 nor UE-B 12, as the UE cannot look inside the token. When 
the first token is de-crypted, the entries will look like: . 

M Route: 

30 



35 



10 

[IV] Route: 



15 



p-cscf-a, 
s-cscf-a, 
as1, 

s-cscf-a, 

i-cscf-a1 t 

i-cscf-a2, 
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which can be represented as: 10, 6, 7, 8, 9, 5, (...). 
However, the correct routing order should look like: 



5 [VI] Route: p-cscf-a, 

i-cscf-a1, 
s-cscf-a, 
as1, 

s-cscf-a, 

10 i-cscf-a2, 



15 



token(s-cscf-b, i-cscf-b1)@home2.net;tokenized- 

by=home2.net, 

i-cscf-b2, 

p-cscf-b ' ■'. 



which can be represented as: 10, 9, 8, 7, 6, 5 (...)• 



Hence, the user is not capable to reverse the entries within tokens as the UE is not 
capable to look inside the tokens. Furthermore the request may then be sent to 
any l-CSCF in the home network, not specifically to the one, which should be the 
20 first on the route. 

SUMMARY OF THE INVENTION 

It ,is therefore an object of the present invention to provide a method and device for 
processing a routing header, by means of which routing errors due to encryption of 
25 multiple names or addresses into one token can be prevented. 

This object is achieved by a method of processing a routing information in a 
packet data network, said method comprising the steps of: 

• extracting said routing information from a received message at a border be- 
tween a first network and a second network; 
30 • adding at least one invalid entry to first-network entries of said routing in- 
formation, said first-network entries relating to a routing path of said mes- 
sage within said first network;. 
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generating an encrypted routing information by encrypting said at least one 
invalid entry and said first-network entries by using an own token at least for 
each of said first-network entries; 

replacing said routing information of said received message by said en- 
crypted routing information; and 

forwarding said received message with said encrypted routing information 
to said second network. 

Furthermore, the above object is achieved by a network device for processing a 
10 routing information in a packet data network, said device comprising: 

• extracting means for extracting said routing information from a received 
message at a border between a first network and a second network; 

• adding means for adding at least one invalid entry to first-network entries of 
said routing information, said first-network entries relating to a routing path 

15 of said message within said first network; 

• encrypting means for generating an encrypted routing information by en- 
crypting said at least one invalid entry and said first-network entries by us- 
ing an own token at least for each of said first-network entries; 

• replacing means for replacing said routing information of said received 
20 message by said encrypted routing information; and 

• forwarding means for forwarding said received message with said en- 
crypted routing information to said second network. . 

Each of the first-network entries may comprises name and/or address information 
25 of a network node through which said received message has been routed. 

Additionally, the above object is achieved by a method of processing a routing inr 
formation in a packet data network, said method comprising the steps of:. 

• extracting said routing information from a received message at a border be- 
30 tween a first network and a second network; 

• generating a decrypted and reversed routing information by decrypting a to- 
kenized second-network entry relating to a routing path of said message 
within said second network and by reversing the content of the decrypted 
second-network entry; 

35 • replacing said routing information of said received message by said de- 
crypted and reversed routing information; and 

• forwarding said received message with said decrypted and reversed routing 
information to said second network. 



5 
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Finally, the above object is achieved by a network device for processing a routing 
information in a packet data network, said device comprising: 

• extracting means for extracting said routing information from a received . 
5 message at a border between a first network and a second network; 

• decrypting and reversing means for generating a decrypted and reversed 
routing information by decrypting a tokenized second-network entry relating 
to a routing path of said message within said second network and by re- 
versing the content of said decrypted second-network entry; 

10 • replacing means for replacing said routing information of said received 
message by said decrypted and reversed routing information; and 

• forwarding means for forwarding said received message with said de- 
crypted and reversed routing information to said second network. 

15 The tokenized first-network entry may comprise encrypted name and/or address 
information of a sequence of network nodes through which the received message 
has been routed. 

The border between said first and second networks may be defined at a gateway 
20 device which the message traverses on a connection between said first and sec- 
ond, networks. 

Accordingly, alternative simple but effective solutions for the above sequencing 
problem can be provided. According to the first alternative solution in the proposed 

25 encryption processing, the l-CSCF(THIG) does not encrypt entries of other I- 

CSCFs. Moreover, instead of generating one token per tokenization process, the I- 
CSCF(THIG) creates multiple tokens, of which some are invalid. Also every valid 
token has only one entry, while invalid tokens may comprise one or more invalid 
entries. This allows to preserve the order of the Record-Route header entries and 

30 to hide the amount of switches that have been traversed in the home network. In 
the proposed decryption processing invalid entries in the Route header are silently 
discarded when encountered. Another way is to. not discard invalid entries during 
the decryption but during the routing. 

35 According to second alternative solution in the proposed encryption processing, 
the l-CSCF does not encrypt entries of its own. Moreover, l-CSCF(THIG) 
generates one token per tokenization process. So a token may contain one or 
more entries. This allows to hide the amount of switches that have been traversed 
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in the home network. In the proposed decryption processing, the content of a to- 
kenized or encrypted entry in the routing header is reversed after decryption. The 
size of the Record-Route and Route headers therefore does not have to be in- 
creased during encryption e.g. by invalid entries or tokens restricted to single 
5 names or addresses like in the first alternative solution. This prevents processing 
overhead for distinguishing and removal of invalid entries after decryption. 

The tokehized network entry of ah incoming and/or outgoing tokenizing network 
node may be marked, and the reversing operation may be suppressed at outgping 

10 tokenizing network nodes. As an alternative, network entries may be reversed at 
incoming tokenizing network nodes before encryption. Thus, the reversing opera- 
tion can be suppressed at the decryption because the entries are already in the 
correct order. Thereby, a problem can be solved which occurs when the Record- 
Route header is used as the Route header e.g. in a resppnse message. 

15 . , / 

The concerned packet data network may comprises an IP Multimedia Subsystem. 
Then, the network device may comprises an Interrogating Call Session Control 
Function. 

20 The routing information may be conveyed in a routing header of the message. This 
routing header can be a Record-Route header or a Route header or Via header of 
a Session Initiation Protocol message. 

The processing method may be a method for topology hiding in said packet data 
25 network. Optionally, the topology hiding method may be applied in response to a 
user identity marked with a predetermined information. In particular, the topology 
hiding method may be applied in response to a network identity. Thereby, topology 
hiding can be applied individually against single users as well as against all users 
of the hiding network. Topology hiding can also be applied individually against sin- 
30 gle users as well as against all users of any foreign network. 

Other advantageous developments of the present invention are defined in the de- 
pendent claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will now be described on a basis of preferred embodiments 
35 with reference to the accompanying drawings, in which: 
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Fig.1 shows an IMS network architecture in which the present invention can be 
implemented; 

Fig. 2 shows a schematic signalling and processing diagram of a header encryp- 
tion processing according to a first preferred embodiment; and 

5 Fig. 3 shows a schematic signalling and processing diagram of a header decryp- 
tion processing according to a second preferred embodiment. 



DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The preferred embodiments will now be described on the basis of an IMS network 
10 architecture as shown in Fig. 1. 

According to the first preferred embodiment, header encryption processing is 
modified in that l-CSCF's do not encrypt entries of other l-CSCFs. Additionally, 
instead of generating one token per tokenization process, the l-CSCF creates mul- 
tiple tokens, of which some are invalid. This allows to preserve the order of the 
1 5 Record-Route header entries and to hide the amount of switches that have been 
traversed in the home network. 

Fig. 2 shows a schematic processing and signalling diagram indicating the proc- 
essing steps or functions at'the l-CSCFs (THIG) 30, 32, 34 and 36 of the network 
configuration shown in Fig. 1 . When a SIP request or message is received at the 

20 concerned l-CSCF (THIG) in step 1 , the Record-Route header is extracted in. step 
2 and invalid entries are added in step 3 to blurr or hide the actual number of rout- 
ing entries which correspond to routing nodes through which the SIP request has 
been routed. Then, the relevant entries, i.e. entries which correspond to routing 
nodes located within the network of the concerned l-CSCF (THIG), are separately 

25 encrypted or tokenized in step 4 by using one token for each individual routing en- 
try. Then, in step 5, the received Record-Route header is replaced by the new Re- 
cord-Route header as processed in the above steps 3 and 4, and the SIP request 
is forwarded or routed via the network border to the neighboring network. 

Therefore, for the initially described example, the Record-Route header [III] could 
30 e.g. look like: 
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[lll->VII] Record-Route: p-cscf-b, 

i-cscf-b2, 

5 token(s-cscf-b) @home2.net;tokenized-by=home2.net, 

token(invalid)@home2.net;tokenized-by=home2.net, 
i-cscf-b1, 
i-cscf-a2, 

token(s-cscf-a)@homei.net;tokenized-b 
10 token(asf) @home1:net;tokenized-by=home1.net, 

token(s-cscf-a) @home 1 .net;tokenized-by=home1 .net, 
token(invalid) @home1.net;tokenized-by=home1.net, 
token(invalid) @home1 .net;tokenized-by-home1 .net, 
i-csct-a1, 

15 p-cscf-a 

and therefore the UE-A 10 would be able to reverse the order when creating the 
Route header: 

20 v 

p-cscf-a, 
i-cscf-a1, 

token(invalid) @home1.net;tokenized-by=home1.net, 
token(invalid) @home1 .net;tokenized-by=home1 .net, 
token (s-cscf-a) @home1 .net;tokenized-by=home1 .net, 
token(asl) @home1 .net;tokenized-by=home1 .net, 
token(s-cscf-a) @home1 .net;tokenized-by=home1 .net, 
i-cscf-a2, 
i-cscf-b1, 

token(invalid)@home2.net;tokenized-by^home2.net, 
token (s-cscf-b) @home2.net;tokenized-by-home2.net, 
i-c$cf-b2, 
p-cscf-b 



[VIII] Route: 



25 



30 
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Thus, the correct routing sequence can be derived at the receiving-side. The inva- 
lid entries may be detected based on the respective content of the name and/or 
address information. This may be achieved e.g. by comparing the content with a 
5 list of valid contents or by adding a flag or marking invalid entries by any other 
suitable mechanism. As an alternative, invalid tokens may as well comprise more 
than one invalid entry. 

According to the second preferred embodiment, header decryption processing is 
10 modified in that the content of a tokenized entry in the Route header is reversed 
whenever an l-CSCF(THIG) decrypts it. The order or sequence of entries in a to- 
ken, which contains.multiple entries, in the Route header is simply reversed after- 
the token has been decrypted. The original token is replaced with the result. 

15 Fig. 3 shows a schematic processing and signalling diagram indicating the proc- 
essing steps or functions at the l-CSCFs (THIG) 30, 32, 34 and 36 of the network 
configuration shown in Fig. 1 . When a SIP request or message is received at the 
concerned l-CSCF (THIG) in step 1, the Route header is extracted in step 2 and 
relevant tokenized entries, i.e. tokenized entries which correspond to a routing 

20 path or sequence located within the network of the concerned l-CSCF (THIG), are 
decrypted in step 3. Then, the content of the decrypted entry is reversed with re- 
spect to the routing sequence (step 4). In step 5, the received Route header is re- 
placed by the new Route header as processed in the above steps 3 and 4, and the 
SIP request is forwarded or routed from the network border to the network. 



25 



In the following example, it is assumed that the elements on the path from UE-A 
10 to UE-B 12 are the following: , 



UE-A 1 0 -» P-CSCF-A 20 -» network border I-CSCF-A1 (THIG) 30 -» 
30 S-CSCF-A 40 -> AS1 60 -> S-CSCF-A 40 l-CSCF-A2(THIG) 34 -» network 
border -> I-CSCF-B1 (THIG) 32 -> S-CSCF-B 42 -+ l-CSCF-B2(THIG) 36 -> net- 
work border -> P-CSCF-B 22 -> UE-B 12. 



35 The Record-Route header as received e.g. in the INVITE request by UE-B 12 
would look as follows: 
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Record-Route: p-cscf-b, 

i-cscf-b2, 

5 token(s-cscf-b, hcscf-b1)@home2.net;tokenized- 

by-home2.net, 
i-cscf-a2, 

token (s-cscf-a, as1, s-cscf-a, i-cscf-a1)@home1. net; token- 
ized-by=home1.net, 
10 p-cscf-a 

The Record-Route header is then returned towards the UE-A 10 in the response. 
The l-CSCF-B2(THIG) 36 on the path of the response to the UE r A 10 decrypts the 
to ken ized entry tokenized-by its own network. The result would be: 

15 ' - • ; : • '. ' • - 

Record-Route: p-cscf-b, 

i-cscf-b2, 

s-cscf-b, 

i-cscf-b1, 

20 i-cscf-a2, 

token (s-cscf-a, as1, s-cscf-a, i-cscf-a1)@home1. net; token- 

ized-by=home1.net, 

p-cscf-a 

25 The l-CSCF-BI(THIG) 32 on the path of the response to UE-A 10 encrypts the 
entries of the own network 82 except its own entry. The result would be: 

p-cscf-b, 

token(i-cscf-b2, s-cscf-b)@home2.net;iokenized- 
by=horne2.net, 

i-cscf-b1, 

i-cscf-a2, 

token (s-cscf-a, as1, s-cscf-a, i-cscf-a1)@home1. net; token- 
ized-by=home1 .net, 
p-cscf-a 

The l-CSCF-A2(THIG) 34 on the path of the response to UE-A 1 0 decrypts the 
tokenized entry tokenized-by its own network 72. The result would be: 



Record-Route: 

30 



35 
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Record-Route: p-cscf-b, 

tbken(i-cscf-b2, s-cscf-b)@home2.net;tokenized- 
5 by=home2.net, 

i-cscf-b1, 
. i-cscf-a2, 
s-cscf-a, 

as 7, • . - ■ 

10 s-cscf-a, 

i-cscf-a1, 
p-cscf-a 

The I-CSCF-A1 (THIG) 30 on the path of the response to UE-A 10 encrypts the 
15 entries of the own network 72 except its own entry. The result would be: 

Record-Route: p-cscf-b , 

token(i-cscf-b2, s-cscf-b)@home2.net;tokenized- 
by-home2.net, 
20 i-cscf-b1, 

token(i-cscf-a2, s-cscf-a, As1, s-cscf^a)@home1. net; token 

ized-by-home1.net, 

i-cscf-a1, ' 

p-cscf-a 

25 '. • 

Now, the UE-A 10 sends a subsequent request e.g. PRACK along the recorded 
route. Therefore it creates the Route header by simply reversing the order of the 
Record-Route entries which is normal SIP procedure. The result would be: 

30 Route: p-cscf-a, 

i-cscf-a1, 

token(i-cscf-a2, s-cscf-a, As1, s-cscf-a)@home1 .net; token 

ized-by-home1.net, 

i-cscf-b1, 

35 token(i-cscf-b2, s-cscf-b)@home2.net;tokenized- 

by-home2.net, 
p-cscf-b 
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The I-CSCF-A1 (THIG) 30 on the path of the request to UE-B 12 first removes its 
own entry and then decrypts the tokenized entry tokenized-by its own network 72 
, and makes reverse and replaces the tokenized entry with the result. The result 
would be: 

5 • . ' ' . ' : ' ' ; . 

Route: s-cscf-a, 
. As1, 
s-cscf-a, 
i-cscf-a2, • 
10 :.\ i-cscf-bt, 

token(i-cscf-b2, s-cscf-b)@horhe2.net;tokenized- 

by=home2.net t - . 

p-cscf-b 

15 Finally, the >CSCF-B1 (THIG) 32 on the path of the request to UE-B 12 first re- 
moves its own entry and then decrypts the tokenized entry tokenized-by its own 
network and makes reverse and replaces the tokenized entry with the result. The 
result would be: 

20 Route: s-cscf-b, 

i-cscf-b2, 
p-cscf-b. 

Consequently, correct decryption of tokenized or encrypted name or address in- 
25 ' formation in the routing header can be assured. . 

However, the above solution according to the second preferred embodiment does 
not solve the case where the content of the Record-Route header is used for the 
Route header from UE-B 12 to UE-A 10. In this case, the encrypted entry is not 
30 reversed at the l-CSCF(THIG) functions/entities that are entry points on the path to 
a network i.e. are located nearest to the header content replacing party in the net- 
work in question. . 



35 



To achieve this, the incoming, i.e. the first, l-CSCF(THIG) of the network and the 
outgoing, i.e. the second, l-CSCF(THIG) of the network have to be distinguished. 
This should be done when routing the initial request sent from the UE-A 10 so that 
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an indication is included into the name/address (SIP URI) of the first I- 
CSCF(THIG) when the first l-CSCF(THIG) inserts its name/address into the Re-' 
cord-Route header of the initial request. The content of the Record-Route header 
is returned in the response and is used as reversed to build the Route header of 

5 the subsequent requests sent from the UE-A 10. Normally, the indication should 
not be included in the name/address of the l-CSCF(THIG) already at the registra- 
tion inserting it into the name/address of the l-CSCF(THIG) in the Path header 
where it would be copied to Service-Route header because the Service-Route 
header is normally built in the S-CSCF so that it contains only entries for the S- 
10 CSCF and the l-CSCF(THIG) in the correct order, i.e., ready to be used in Route 
header preserving the order. It is noted that the Record-Route header has to be 

. ' reversed before used in Route header by the originating party. 

Alternatively, an indication can be included in the name/address of the outgoing 
15. i.e. the second l-CSCF(THIG) when the request is forwarded to it in order to be 
routed out from the network. 

The indication may be a sign, a tag, a mark or the like, e.g.. a parameter, a port, a 
bit/character string in the user part and/or host-domain part or alike included in the 
20 name/address or associated to the name/address of the l-CSCF(THIG). 

When marking the first and second l-CSCF(THIG), respectively/the following ex- 
amples could be used: 

25 ^'first@i-cscf.home.net" and "second@i-cscf.home.net"; 
"firsti-cscf.home.net" and "second.i-cscf.home.net"; 
"i-cscf.home.net: 12233" and "i-cscf.home.net:12234"; 

> - * ' 

30 

"i-cscf.home.net;first" and "i-cscf.home.net;second"; or 
"i-cscf.home.net;order=first" and "i-cscf.home.net;order=second". 
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l.n the following example which is based on the above example of the second pre- 
ferred embodiment, it is described how the second l-CSCF(THIG) shall handle 
requests (not to reverse after decryption) originated from UE-B 1 2. 
5 ,. 

A string "FIRST" in the user part is used as an example of an indication identifying 
l-CSCF(THIG) as the incoming i.e. the first l-CSCF(THIG) in the network. The out- 
going, i.e. the second l-CSCF(THIG), is not indicated. 

10 Record-Route header as received in INVITE by UE-B would be: 

Record-Route: p-cscf-b, 

i-cscf-b2, 

' token(s-cscf-b,first@i-cscf-b1)@home2.net ;tokenised- 
15 by-home2.net, 

i-cscf-a2, 

token (s-cscf-a, as1, s-cscf-a, first@i-cscf- 

a1)@home1.net;tokenized-by=home1.net, 

p-cscf-a 

20 . 

The Record-Route header is returned towards UE-A 10 in the response. 

The recorded route i.e. the content of the Record-Route header is also stored by 
UE-B 1 2. When the UE-B 1 2 sends a BYE request to the UE-A 1 0, the stored re- 
25 corded route is used as route * i.e., in the Route header of the BYE request. Each 
network entity removes its own entry from the top of the Route header when it re- 
ceives the request. The content of the Route header would look as follows in vari- 
ous steps on the path: - 

30 Route header in BYE request when sent from UE-B 12 would be: 



Route: 



p-cscf-b, 
i-cscf-b2, 
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token(s-cscf-b, first@i-cscf-b1)@home2.net Jokenized- 

by-home2.net, 

i-cscf-a2, 

token(s-cscf-a, as1, s-cscf-a, first@i-cscf- ; 
5 a1)@home1.net;tokenized-by=home1.net, 

p-cscf-a 

The l-CSCF-B2(THIG) 36 on the path of the request to UE-A 10 decrypts the to- 
kenised entry tokenised by its own network. The result is not reversed because 
10 there is no indication that this l-CSCF(THIG) would be the first l-CSCF(THIG) of 
the network. The result would be: 

Route: s-cscf-b, 

first@i-cscf-b1 , 
15 i-cscf-a2, 

token(s-cscf-a, as1, s-cscf-a, first@i-cscf- 

a1)@home1.net;tokenized-by=home1.net, 

p-cscf-a 

20 • The I-CSCF-BI(THIG) 32 on the path of the request to UE-A 10 encrypts the en- 
tries of the own network except its own entry . This has no influence on the Route 
header because there are no entries left belonging to the own network. 

Route: . i-cscf-a2, 

25 token (s-cscf-a, as1 t s-cscf-a, first@i-cscf- 

a1)@home1.net;tokenized-by=home1.net, 
p-cscf-a 

The l-CSCF-A2(THIG) 34 on the path of the request to UE-A 10 decrypts the to- 
30 kenised entry tokenised by its own network. The result is not reversed because 
there is no indication that this l-CSCF(THIG) would be the first l-CSCF(THIG) of 
the network. The result would be: 
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s-cscf-a, 
as1, 

s-cscf-a, . 
first@i-cscf-a1, 
p-cscf-a 

The I-CSCF-A1 (THIG) 30 on the path of the request to UE-A 10 encrypts the en- 
tries of the own network except its own entry. This has no influence in the Route 
header because there are no entries left belonging to the own network. The result 
10 would be: 

Route: p-cscf-a 

The request is routed to the P-CSCF-A 20 and further to UE-A 10. 

Implementation where the outgoing, i.e. the second, l-CSCF(THIG) is indicated is 
straight forward. The functionality is the same, i.e. the reverse is done in the in- 
coming, i.e: the first, UCSCF(THIG) of the network. It doesn't matter whether the 
name/address of the incoming (i.e.. the first) l-CSCF(THIG) or the outgoing (i.e. the 
20 second) l-CSCF(THIG) carries the indication. If the first l-CSCF(THIG) is indicated, 
the l-CSCF(THIG) reverses the list of entries after decryption when its 
name/address carries the indication. If the second I-CSCF(THIG) is indicated, the 
l-CSCF(THIG) reverses the list of entries after decryption when its name/address 
doesn't carry the indication. 

25 

: In short, the indication is only a means to distinguish the incoming (i.e. the- first) 

and outgoing (i.e. the second) l-CSCF(THIG) of the network. The operation to re- 
. verse the list of entries after decryption is done in the incoming (i.e. the first) I- 
CSCF(THIG) of the network. 

30 

As an alternative, instead of reversing in the Route header when needed, revers- 
ing can be performed already beforehand in the Record-Route header. 



Route: 



5 
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Instead of reversing by the incoming (i.e. the first) l-CSCF(THIG) the tokenized 
entries in the Route header of the subsequent requests from UE-A 10, the same I- 
CSCF(THIG) (i.e. the incoming or first l-CSCF(THIG)) reverses the same entries 
already before it tokenizes them in the Record-Route header of a response for- 
5 warded to the direction of UE-A 10. 

In the following example which is based on the above example of the second pre 
ferred embodiment, a practical implementation of the alternative option is de 
scribed. 

10 ' ■■• * v . ; . 

The Record-Route header as received in INVITE by UE-B 12 would be: 

Record-Route: p-cscf-b, 
- i-cscf-b2, 
15 token(s-cscf-b,first@i-cscf-b1)@home2.ne 

by=home2.net, 
i-cscf-a2, 

token(s-cscf-a, as1, s-cscf-a, /7rsf@/-cscf- 
a i)@home 1 .net;tokenized-by=home l.net, 
20 . ^ p-cscf-a 

The Record-Route header is returned towards UE-A 10 in the response. 

The l-CSCF-B2(THIG) 36 on the path of the response to UE-A 10 decrypts the 
25 tokenised entry tokenised by its own network. The result would be: 

Record-Route: . p-cscf-b, 

i-cscf-b2, 
s-cscf-b f 

30 first@hcscf-b1, 

i-cscf-a2, 

token (s-cscf-a, as1, s-cscf-a, first@i-cscf- 
a1)@home1.net;tokenized-by=home1.net, 
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p-cscf-a 

The l-CSCF-BI(THIG) 32 on the path of the response to UE-A 10 encrypts the 
entries of the own network except its own entry. The lists of entries is reversed 
5 before encryption because there is an indication that this l-CSCF(THIG) is the first 
l-CSCF(THIG) of the network. The result would be: 

Record-Route: p-cscf-b, 

tokeh(s-cscf-b, i-cscf-b2)@home2.net;tokenized- 
10 . . . by=home2.net, 

first@i-cscf-b1; 
i-cscf-a2, 

token (s-cscf-a, as1, s-cscf-a, first@i-cscf- 
a1)@home1 .net;tokenized-by=home1 .net, 
15 p-cscf-a 

The l-CSCF-A2(THIG) 34 on the path of the response to UE-A 10 decrypts the 
tokenised entry tokenised by its own network. The result would be: 

p-cscf-b, 

token(s-cscf-b, i-cscf-b2)@home2.net;tokenized- 
by=home2.net, 
first@i-cscf-b1 , 
i-cscf-a2, 
s-cscf-a, 
as1> 

s-cscf-a, 
first@i-cscf-a1, 
p-cscf-a 

The l-CSCF-AI (THIG) 30 on the path of the response to UE-A 10 encrypts the. 
entries of the own network except its own entry. The lists of entries is reversed 



20 . 

Record^Route: 



25 



30 
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before encryption because there is an indication that this l-CSCF(THIG) is the first 
l-CSCF(THIG) of the network: The result would be: 

Record-Route: p-cscf-b, 
5 . token(s-cscf-b, hcscf-b2)@home2.net;tokenized- 

by-home2.net, 
first@i-cscf-b1 , 

token(s-cscf-a, As1, s-cscf-a, i-cscf- 
a2)@home1 .net;tokenized-by=home1 .net, 
10 first@i-cscf-a1, 

', p-cscf-a 

Now, the UE-A 10 sends a subsequent request, e.g. PRACK, along the recorded 
route. Therefore it creates the Route header by simply reversing the order of the 
15 Record-Route entries which is normal SIP procedure. The result would be: 

Route: p-cscf-a, 

first@i-cscf-a1, 

:token(s-cscf-a, As1, s-cscf-a, i-cscf- 
20 a2)@home1.net;tokenized-by=home1.net, 

first@i-cscf-b1 , 

token(s-cscf-b, i-cscf-b2)@home2.net;tokenized- 

by=home2.net f 

p-cscf-b 



25 



30 



The l-CSCF-AI(THIG) 30 on the path of the request to UE-B 12 first removes its 
own entry and then decrypts the tokenised entry tokenised-by its own network and 
makes no reverse because it is already done in Record-Route and replaces the 
tokenised entry with the result. The result would be: 

Route: s-cscf-a, 

As1, 
s-cscf-a, 
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i-cscf-a2, 
first@i-cscf-b1 , 

token(s-cscf-bJ-cscf-b2)@home2.net;tokenized- 

by=home2:net, 

p-cscf-b 

The l-CSCF-A2(THIG) 34 on the path of the request to UE-B 12 encrypts the en- 
tries of the own network except its own entry. This has no influence on the Route 
header because there are no entries left belonging to the own network. The result 
would be: 



Route: first@i-cscf-b1 , 

token(s-cscf-bJ-cscf-b2)@home2.net;tokenized- 

by-home2.net, 

p-cscf-b 

The l-CSCF-B1(THIG)32 on the path of the request to UE-B 12 first removes Its 
own entry and then decrypts the tokenised entry tokenised-by its own network and 
makes no reverse because it is already done in Record-Route and replaces the 
tokenised entry with the result. The result would be: 

Route: s-cscf-b, 

i-cscf-b2, 
p-cscf-b 

The l-CSCF-B2(THIG) 36 on the path of the request to UE-B 12 encrypts the en- 
tries of the own network except its own entry. This has no influence on the Route 
header because there are no entries left belonging to the own network. The result 
would be: 



Route: 



p-cscf-b 
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As in the above preceding example, also here the implementation where the out- 
going, i.e. the second, l-CSCF(THIG) is indicated is straight forward, 

As said earlier in the preceding example, the indication is only a means to distin- 
guish the incoming (i.e. the first) and outgoing (i.e. the second) l-CSCF(THIG) of 
the network. The operation to reverse the list of entries before encryption is done 
in the incoming (i.e. the first) l-CSCF(THlG) of the network. 

The incoming and/or outgoing l-CSCF(THIG) of the network are thus marked so 
that the content of the tokenised Route header entry can be reversed in the incom- 
ing l-CSCF(THIG) after decryption but not in the outgoing l-CSCF(THIG). This (i.e. 
not to reverse) is needed in the case where UE-B 12 sends a, request to UE-A 10 
using the route stored from Record-Route header of the initial request from UE-A 
10.. • . . • • 

It is also possible that in the examples described above the P-CSCF-A 20 and/or 
the P-CSCF-B 22 belongs to the home network of the UE-A 10 and/or the UE-B 
12. respectively. In that case the l-CSCF-AI(THIG) 30 and/or l-CSCF-B2(THIG) 
36 does not encrypt the entry of P-CSCF-A 20 and/or P-CSCF-B 22, respectively. 

So far, the hiding functionality, i.e. the network topology hiding, is specified only 
between networks and mainly because of business reasons. It is quite evident that 
the hiding cannot fulfil this requirement because users may freely buy a subscrip- 
tion of the hiding operator and register to that, i.e. to the hiding, network. Thus, a 
user is able to see the signalling using a terminal provided with proper software 
tools and modifications when registered in the home network (i.e. in the hiding 
network) because hiding is used only when the user registers from a foreign net- 
work (if hiding is applied to that foreign network). 

It also seems to be a trend that hacking against IP networks increases using virus 
and other means. So it may be wise to hide as much of the topology of the net- 
work as possible also in home networks. 
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It is thus suggested for the first and second preferred embodiments, that the I- 
CSCF(THiG) is kept on path also when the UE is registered from the home net- 
work. If hiding is applied individually against single users, the l-CSCF is kept on 
path when the user has a signal in the subscription information that hiding shall be 
5 applied. 

To achieve this, the name/address of the l-CSCF can be inserted into the Service- 
Route header during the registration. If hiding should be applied, the I- 
CSCF(THIG) inserts its name/address to the Path header of REGISTER message. 

10 Then, the S-CSCF builds the Service-Route header and inserts the name/address 
of the l-CSCF(THIG) if hiding shall be applied. So the S-CSCF makes the final 
decision when hiding should be used. This makes it possible to apply hiding 
against certain users only. Before the decision, the S-CSCF has already 
downloaded the user's subscription information from the HSS as part of the regis- 

1 5 tration procedure. That information may contain a tag for those users against 
whom the network topology hiding has to be applied. 

The S-CSCF may build the Service-Route so that it contains name/address of the 
l-CSCF(THIG) also when the user is registering from the same network, i.e.; from 
20 its home network. So hiding can be applied inside the hiding network. The P- 

CSCFs are the only network elements (in addition to I-CSCF(THIG)s) that cannot 
be hidden with this procedure. 

Thus, the idea is to put the l-CSCF(THIG) on the path either always (hiding ap- 
25 plied also inside the hiding network) or based on the user identity (hiding applied 
against certain users independently whether they register from home or foreign i.e. 
visited network). This makes topology hiding applicable individually against single 
users as well as against all users registered in the home network, i.e. in the hiding 
network, and can be achieved by a simple addition to the existing functionality. 

30 

In summary, a method and network device for processing a routing information in 
a packet data network is proposed, wherein the routing information is extracted 
from a received message at a border between a first network and a second net- 
work, and at least one invalid entry is added to first-network entries of the routing 
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information. The first-network entries relate to a routing path of the message within 
the first network. The at least one invalid entry and the first-network entries is en- 
crypted by using an own token at least for each of the first-network entries. As an 
alternative, a tokenized second-network entry extracted from said routing informa- 
tion and relating to the routing path of the message within the second network is. 
decrypted, and its content is reversed. In both cases/the routing information is 
replaced by the processed routing information and the message is forwarded to 
the second network. This allows to preserve the order of routing entries and to 
hide the amount of switches that have been traversed in the home network. 

It is noted that the present invention is not restricted to the preferred embodiments 
described above. The present invention may be implemented in any network node 
having a routing information encryption and/or decryption functionality in any net- 
work. In particular, any header or payload fields of any packet data message or 
datagram may be used for transferring the routing information.The'embodiments 
may thus vary within the scope of the attached claims. 
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Claims 
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1 . A method of processing a routing information in a packet data network, said 
method comprising the steps of: 

a) extracting said routing information from a received message at a border 
5 ■ between a first network and a second network; 

b) adding at ieast one invalid entry to first-network entries of said routing 
information, said first-network entries relating to a routing path of said 
message within said first network; 

c) generating an encrypted routing information by encrypting said at least 
10 one invalid entry and said first-network entries by using an own token at 

least for each of said first-network entries; 

d) replacing said routing information of said received message by said en- 
crypted routing information; and 

e) forwarding said received message with said encrypted routing informa- 
15 tion to said second network. , 

2. A method according to claim 1, wherein said routing information is conveyed 
in a routing header of said message. 

20 3. A method according to claim 2, wherein said routing header is a Record- 
Route header of a Session Initiation Protocol message or a Service-Route 
header as specified for the Session Initiation Protocol. 

4. A method according to any one of the preceding claims, wherein said proc- 
25 . essing method is a topology hiding method. 

5. A method according to claim 4, wherein said topology hiding method is ap- 
plied in response to a user identity marked with a predetermined information. 

30 6. A method according to claim 4, wherein said topology hiding method is ap- 
plied in response to a network identity. 



7. 



A method according to any one of the preceding claims, further comprising 
the step of marking said at least one added invalid entry. 
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8. A method according to any one of the preceding claims, wherein each of said 
first-network entries comprises name and/or address information of a network 
node through which said received message has been routed. 

5 9. A method according to any one of the preceding claims, wherein said border 
between said first and second networks is defined at a gateway device which 
said message traverses on a connection between said first and second net- 
works. 

1 0 10. A network device for processing a routing information in a packet data net- 
work, said device (30, 32, 34, 36) comprising: 

a) , extracting means for extracting said routing information from a received 

message at a border between a first network and a second network; 

b) adding means for adding at least one invalid entry to first-network en- 
15 tries of said routing information, said first-network entries relating to a 

routing path of said message within said first network; 

c) . encrypting means for generating an encrypted routing information by 

encrypting said at least one invalid entry and said first-network entries 
by using an own token at least for each of said first-network entries; 
20 ' d) replacing means for replacing said routing information of said received 

message by said encrypted routing information; and 
e) forwarding means for forwarding said received message with said en- 
crypted routing information to said second network. 

25 11. A network device according to claim 10, wherein said network device com- 
" prises an Interrogating Call Session Control Function and/or a Topology Hid- 
ing Gateway function. 

12. A network device according to claim 10 or 1 1 , wherein said packet data net- 
30 . work comprises an IP Multimedia Subsystem. 

13. A network device according to any one of claims 10 to 12, wherein said bor- 
der between said first and second networks is defined at said network device. 

35 14. A method of processing a routing information in a packet data network, said 
method comprising the steps of: 

a) extracting said routing information from a received message at a border 
between a first network and a second network; 
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b) generating a decrypted and reversed routing information by decrypting 
a tokenized second-network entry relating to a routing path of said 
message within said second network and by reversing the content of 
the decrypted second-network entry; 

c) replacing said routing information of said received message by said de- 
crypted and reversed routing information; and 

d) forwarding said received message with said decrypted and reversed 
routing information to said second network. 

15. A method according to claim 14, wherein said routing information is con- 
veyed in a routing header of said message. . 

16. A method according to claim 15, wherein said routing header is a Route 
header or a Via header of a Session Initiation Protocol message. 

. . - •■ • - '',/.-• 

17. A method according to any one of claims 14 to 16; wherein said processing 
method is a topology hiding method. 

18. A method according to claim 17, wherein said topology hiding method is ap- 
plied in response to a user identity marked with a predetermined information. 

19. A method according to claim 17, wherein said topology hiding method is ap- 
plied in response to a network identity. 

20. A method according to any one of claims 14 to 19, wherein said tokenized 
second-network entry comprises encrypted name and/or address information 
of a sequence of network nodes through which said received message has 
been routed. 

21. A method according to any one of claims 14 to 20, further comprising the 
steps of marking a tokenized network entry of an incoming and/or outgoing 
tokenizing network node, and suppressing said reversing step at outgoing to- 
kenizing network nodes. 

22. A method according to any one of claims 14 to 2i, further comprising the 
steps of marking a tokenized network entry of an incoming and/or outgoing 
tokenizing network node, and reversing network entries at incoming tokeniz- 
ing network nodes before encryption. 
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23. A method according to any one of claims 14 to 22, wherein said border be- 
tween said first and second networks is defined at a gateway device which 
said message traverses on a connection between said first and second net- 
works. 

24. A network device for processing a routing information in a packet data net- 
work, said device (30, 32, 34, 36) comprising: 

a) extracting means for extracting said routing information from a received 
message at a border between a first network and a second network; 

b) decrypting and reversing means for generating a decrypted and re- 
versed routing information by decrypting a tokenized second-network 
entry relating to a routing path of said message within said second net- 
work and by reversing the content of the decrypted second-network en- 
try; 

c) replacing means for replacing said routing' information of said received 
message by said decrypted and reversed routing information; and 

d) forwarding means for forwarding said received message with said de- 
crypted and reversed routing information to said second network. 

25. A network device according to claim 24, wherein said network device com- 
prises an Interrogating Call Session Control Function and/or a Topology Hid- 
ing Gateway function. 

26. A network device according to claim 24 or 25, wherein said packet data net- 
work comprises an IP Multimedia Subsystem. 

27. A network device according to any one of claims 24 to 26, wherein said net- 
work device is configured to suppress reversing of said decrypting and re- 
versing means if said routing information indicates that said network device is 
an outgoing tokenizing network node. 

28^ A network device according to any one of claims 24 to 27, wherein said net- 
work device is configured to reverse network entries before encryption if said 
routing information indicates that said network device is an incoming tokeniz- 
ing network node. 
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29. A network device according to any one of claims 24 to28, wherein said bor- 
der between said first and second networks is defined at said network device. 
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The present invention relates to a method and network device for processing a 
routing information in a packet data network. The routing information is extracted 
from a received message at a border between a first network and a second net- 
5 work, and at least one invalid entry is added to first-network entries of the routing 
information. The first-network entries relate to a routing path of the message within 
the first network. The at least one invalid entry and the first-network entries are 
encrypted by using an own token at least for each of the first-network entries. As 
an alternative, a tokenized second-network entry extracted from said routing in- 
10 /formation and relating to the routing path of the message within the second net- 
work is decrypted, and its content is reversed. In both cases, the routing informa- 
tion is replaced by the processed routing information and the message is for- 
warded to the second network. This allows to preserve the order of routing entries 
and to hide the amount of switches that have been traversed in the home network. 
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